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The 10 A Remote Switching System (rss) is unlike previous elec- 
tronic switching systems in that its various subsystems can be physi- 
cally separated by hundreds of miles. Thus, its maintenance plan 
must make provisions for the day-to-day operation and repair of the 
separate system components by different Bell operating company 
craft forces. The maintenance of each of the rss subsystems is de- 
scribed in this article, as well as the required overall coordination 
between the various craft forces charged with rss maintenance. 

I. INTRODUCTION 

1.1 Maintenance objectives 

Overall system requirements and objectives for the 10 A Remote 
Switching System (rss) are detailed in Ref. 1. From a maintenance 
standpoint, the objective is to provide continuous and reliable tele- 
phone service throughout the life of the system, while providing 
maintenance capabilities equivalent to those of other ess systems. 
That is, the system must be both highly dependable and easily main- 
tainable. The maintainability objective is to have a system in which 
troubles, when they occur, are easily located and sectionalized, and 
repair operations can be completed quickly by craft without extensive 
training in rss. It is a further objective that the rss maintenance plan 
be as consistent as possible with existing Bell operating company 
procedures for maintaining switching systems and fit the organiza- 
tional structures and maintenance support systems expected to exist 
in the 1980s. 



597 



1.2 Overview 

The No. 10A rss maintenance plan is similar to that of other Bell 
System electronic switching systems in its reliance upon hardware 
duplication of critical system components and its use of program 
control for fault detection, recovery, and support of repair operations. 
The rss is unique, however, in that its various subsystems can be 
physically separated by up to 280 miles, 2 and the maintenance plan 
must make provisions for the day-to-day operation and repair of 
separate parts of the system by different craft forces. For this reason, 
proper maintenance of the rss will require considerably more coordi- 
nation among various Bell operating company maintenance forces 
than earlier electronic switching systems. 

A block diagram of the rss is shown in Fig. 1. The three major 
components are 

(i) The rss remote terminal. 
(it) The data links and interconnecting channel facilities. 

(Hi) The controlling host ess. 

All of the communication (both voice and data) from the remote 
unit terminates on the host office, which supplies much of the overall 
control for the system. The communication between the remote ter- 
minal and the host ess is over duplicated data links, controlled at the 
host by the Peripheral Unit Controller configured in the Data Link 
application (puc/dl). The voice channels from the remote terminal 
connect to the host line network and, thus, present some characteristics 
of both lines and trunks. Detailed discussions of the software and 
hardware characteristics of the various rss components are included 
in Refs. 1 to 7. 




Fig. 1— Remote switching system block diagram (T carrier). 
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A maintenance plan for the rss must include all of these separable 
subsystems and their interactions. In general, existing host mainte- 
nance procedures have been extended to include the maintenance of 
components of the rss closely tied to the host ess. Thus, the channels 
interconnecting the host and the remote terminal are treated, from a 
maintenance standpoint, much like interoffice voice trunks connected 
to the ess. The puc/dl is treated like any other piece of ess periphery 
and is maintained similarly. 

On the other hand, the remote terminal itself, where the hardware 
is distinctly separate from that of the host, is maintained, as much as 
possible, as a separate entity. The host maintenance teletypewriter 
(tty) is the primary interface for remote terminal maintenance, but 
all remote terminal fault detection, diagnostic control, system state 
control, etc., are coordinated by the microprocessor controller at the 
remote terminal. In this way, most maintenance procedures for the 
rss remote terminal can be kept independent of the host type (No. 1, 
1A, or 2B ess). The specific host-dependent maintenance capabilities 
described in this article refer to No. 1/1A ess. 

The rss per-line circuitry is quite complex because of space, power, 
and network considerations, 4 while the host ess per-line circuitry is 
relatively simple. Extensive loop maintenance functions, such as local 
test desk access and Automatic Line Insulation Tests (alit) exist in 
the host, but there are no line circuit maintenance functions applicable 
to the rss per-line hardware. Host software has been modified to 
supervise alit testing, and to control line test access in the rss. 
Software has been implemented in the remote terminal to provide the 
required per-line circuitry maintenance functions. 

Section II of this paper describes the operational relationships 
necessary to efficiently maintain the rss. Remote terminal mainte- 
nance is discussed in Section III, and puc/dl maintenance is outlined 
in Section IV. Section V reviews the approach to rss channel main- 
tenance, and customer line maintenance is discussed in Section VI. 

II. DIVISION OF MAINTENANCE RESPONSIBILITIES 
2. 1 Overall maintenance coordination 

The primary responsibility for the maintenance of the rss lies with 
the switching force responsible for the maintenance of the host ess. 
The rss sites are unstaffed, with all tty messages from the various 
rsss appearing on the host maintenance tty. All alarms associated 
with the rss trigger host central office audible alarms and light alarm 
indicators on the host Master Control Center (mcc). The sectionali- 
zation of troubles often requires detailed host office expertise because 
of the complex interrelationship between the host and the rss. 

SYSTEM MAINTENANCE 599 



The ess switching maintenance force may be located either in the 
host central office or in the Switching Control Center (sec). When the 
host is maintained from an sec, the sec is the ideal point to centralize 
the overall maintenance responsibility for the rss. The sec is normally 
responsible for the operation and maintenance of all ess central office 
equipment within a geographic area, and its responsibility would 
normally extend to any rsss served by host ess offices in that area. 

The sec is responsible for continuous surveillance and trouble sec- 
tionalization for the rss. Since sec personnel would normally monitor 
all tty printout and host alarms, they are responsible for sectionalizing 
and isolating all machine-generated trouble reports. When a fault is 
found in the host ess equipment, the puc/dl, or the rss remote 
terminal, the sec maintenance force is directly responsible for its 
repair. In some cases, the sec will have direct repair responsibility for 
other portions of the system. In some Bell operating companies, the 
sec is responsible for the maintenance of central office carrier equip- 
ment. When this is the case, sec craft will normally be responsible for 
the maintenance of any host office located channel carrier equipment. 
In all other cases of rss troubles, it is the responsibility of the sec to 
refer other troubles (e.g., customer loop problems, carrier facility 
troubles, or data link modem difficulties) to the appropriate mainte- 
nance force for follow-up repair. The sec is also responsible for tracking 
all RSS repair activities, independent of the specific maintenance force 
responsible for the repair. 

2.2 Remote terminal maintenance 

The repair and maintenance of the rss remote terminal will normally 
be carried out by ess switching craft dispatched from the host central 
office or from the sec. In some cases, however, because of long travel 
times or other local problems, it may be expedient to train other 
available maintenance personnel in simple rss repair procedures. In 
these cases, the repair operations will be performed under the direction 
of switching craft, either at the host or at the sec. 

2.3 Data link maintenance 

All puc/dl faults are reported on the host maintenance tty and are 
treated in the same manner as a fault in any other piece of ess 
periphery. After the trouble is sectionalized and isolated, the host 
switching craft will be responsible for the repair. If the fault is found 
to lie within the data sets, the trouble will be referred to the appropriate 
force (normally either data services or carrier repair forces) for repair. 
If the fault is found to lie within the carrier facilities, those normally 
responsible for carrier maintenance and repair will be called. 
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2.4 Channel maintenance 

The maintenance of the voice channels between the rss remote 
terminal and the host ess is the responsibility of the same force 
responsible for the maintenance of the host office trunks. This function 
will be performed at the host trunk test panel or at the trunk mainte- 
nance work station at the sec. This force will be responsible for 
monitoring the weekly scheduled automatic channel diagnostics, and 
providing ongoing surveillance of the maintenance tty output in order 
to react to channels automatically removed from service by system- 
error analysis. When rss channel troubles are detected, it is the 
responsibility of this force to sectionalize the trouble to either host 
central office equipment, host carrier equipment, carrier facilities, or 
remote terminal equipment. Once the fault is isolated to one of these 
areas, the trunk maintenance force is charged with either repairing the 
trouble, or referring the problem to the appropriate maintenance 
group. 

When the host trunks are included in a Centralized Automatic 
Reporting On Trunk (carot) center, the rss channels will normally 
also be included. Then, the carot center will routinely perform trans- 
mission measurements on the rss channels. 

2.5 Carrier equipment maintenance 

The carrier equipment between the host ess and the rss remote 
terminal is the maintenance responsibility of the Bell operating com- 
pany force normally charged with carrier maintenance. The switching 
craft responsible for the host will normally receive the first indication 
of carrier trouble via tty printouts and audible alarms. The problem 
will then be sectionalized further to determine which specific force 
should carry out the repair. Trouble could lie within the rss remote 
terminal frame, within the host ess carrier equipment, or within the 
carrier facilities in the outside plant. In the case of T-carrier, particu- 
larly, coordination greater than the norm will often be required be- 
tween the switching craft and the force responsible for carrier main- 
tenance, because the T-carrier equipment at the remote terminal is 
integrated into the rss equipment frame. When the switching craft 
has isolated the carrier problem to the facilities, the trouble would 
normally be reported to the Facility Operation Center of the T-carrier 
Restoration Control Center (trcc) for repair and service restoral. 

2.6 Customer loop maintenance 

The responsibility for the maintenance of the customer outside plant 
and station equipment remains with the appropriate maintenance 
center. In the following, such a maintenance center will be referred to 
generically as a Repair Service Bureau (rsb). In the future, rsb 
functions may be split among several other maintenance centers. 
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The ability to test an rss customer loop from the local test desk is 
provided either via a metallic test connection or through a modified 
remote test system. As with other systems, most customer complaints 
will be reported directly to the rsb, and it will be their responsibility 
to sectionalize the problem as either "in" the switching equipment or 
"out" in the outside plant. If the problem is found to be in the switching 
equipment, it is the responsibility of the rsb to notify the switching 
craft for further fault resolution and repair. Customer drop line, 
terminal equipment, and loop plant problems will be repaired by the 
appropriate maintenance force. 

Customer loop problems that are detected by the rss will result in 
tty output messages that print on the local test desk tty channel. It 
will be the responsibility of the rsb maintenance force to react to these 
trouble reports, sectionalize the problem to either "in" or "out" and 
either repair the "out" problem or alert the switching craft to problems 
within the rss equipment. 

III. REMOTE TERMINAL MAINTENANCE 
3.1 System overview 

The rss microprocessor controller generally operates under the 
control of the host ess processor. In the case of call processing, the 
degree of host control is large. 5 However, remote terminal maintenance 
activities are carried out nearly autonomously, with the host ess acting 
primarily as a tty input/output coordinator. Remote terminal hard- 
ware fault detection, error analysis, alarm scanning, and processor 
configuration are performed by the remote terminal microprocessor. 
The rss hardware diagnostics are also resident at the remote terminal. 
The host exercises automatic control over remote terminal hardware 
diagnostics only for interface circuitry, such as channel interface 
hardware and data link hardware. 

The desired degree of remote terminal reliability is accomplished 
through hardware duplication of circuitry that affects more than 64 
customer lines. To ensure that no single fault will affect more than 64 
lines, the rss microprocessor controller and the data link connecting 
the remote terminal to the host are duplicated. A block diagram 
illustrating this duplication is shown in Fig. 2. A complete rss con- 
troller consists of the microprocessor itself, along with its dedicated 
memory and a dedicated set of fanout boards through which the 
periphery is accessed. Each microprocessor controller can communi- 
cate over either data link. The host determines which data link is 
active, and the remote terminal decides which microprocessor con- 
troller is active. 

The remote terminal microprocessor controllers have four allowable 
states: active, standby, out-of-service, and unavailable. In the normal 
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Fig. 2 — Remote switching system terminal — system control. 

working mode, one processor side is active with the other standby. In 
this mode, there is no matching between the two sides, but the standby 
memory is placed in a double- write mode, allowing the active processor 
to write into both the on-line and off-line memories simultaneously. 
Thus, if a fault is detected in the on-line controller, a switch can 
quickly be made to the standby side whose memory has been kept up 
to date. Any data mutilation caused by the fault will be cleaned up by 
initialization and audit routines after the switch. 

If the off-line microprocessor complex is suspected of being faulty, 
or its memory is not being kept up to date, it is placed in the out-of- 
service state. When the off-line microprocessor is marked out-of-ser- 
vice, it is still available for a switch to the active state if a severe fault 
is detected in the on-line controller. The off-line processor is made 
unavailable, and a processor switch inhibited, if it has been manually 
forced off-line or if it has had its power removed. The rss control 
complex is discussed in detail in Ref. 3. 

Peripheral circuitry, such as the network links and junctors, the 
various service circuits, and the voice channels between the host and 
the remote terminal, are replicated. ' If a malfunction occurs in one of 
these circuits, the faulty component is identified and removed from 
service. Generally, there is a sufficient number of remaining circuits to 
adequately handle the normal traffic with little or no degradation of 
service. 

The primary maintenance interface with the rss remote terminal is 
via the host ess maintenance tty. Direct tty communication with the 
remote microprocessor control system is not possible. A maintenance 
panel is provided for on-site interaction with the remote terminal, but 
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its primary function is to allow for circuit-pack replacement and repair 
verification. The capability is provided to verify a failing circuit, 
remove it from service, remove power from the circuit pack if neces- 
sary, replace the pack, and then verify the replacement's correct 
operation. A software buffer associated with the maintenance panel 
must be preloaded, via the host tty, with a list of circuit packs to be 
diagnosed on site. 

During installation and periods when extensive repair activity is 
necessary at the remote site, remote access to the host maintenance 
tty facility is possible. This access will generally be provided via a 
secure dial up connection to the sec serving the host ess. In this case, 
it is recommended that a voice-grade facility, independent of the rss 
equipment, be provided. It is also possible to provide access to the host 
remote maintenance tty on a direct, dedicated-facility basis. 

3.2 Remote terminal fault detection 

The rss remote terminal maintenance programs detect and recover 
from a fault, reconfigure the system if necessary, and report pertinent 
information concerning the fault in a tty output message at the host. 3,6 
Normally, the message will identify the specific circuit in which the 
fault occurred. The detection of a fault does not automatically initiate 
a diagnostic of the remote terminal hardware. It is necessary for the 
craft person to use manual diagnostics to verify and repair the faulty 
circuit. 

Both hardware and software checks are used to detect faults in the 
rss remote terminal microprocessor controller complex. 4 There is a 
hardware sanity timer associated with each microprocessor. If the 
timer is not periodically reset, a timeout occurs, causing the associated 
microprocessor to begin executing code to initialize itself and establish 
a working mode. Repeated timeouts result in more severe initialization 
levels. In addition, hardware exists to detect parity errors when ac- 
cessing the memory and fanout boards. 

Software fault detection is performed by a set of sanity tests that 
are repeated approximately every 10 seconds. These tests are designed 
to fail when the control complex is functioning improperly. 

A software check routine verifies the ability of the processors to 
access the rss periphery. Peripheral faults are also detected by a 
number of tests each time the peripheral equipment is used. These 
include tests for network continuity, tests for proper operation of the 
logic on the line interface boards, and, on terminating calls, tests of 
the universal service circuit output voltage levels and logic operation. 
On terminating calls, proper operation of the high voltage metallic 
access circuitry is verified, and the ringing current on the customer 
loop is measured. The failure of any of these tests results in a report 
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to the error analysis programs. The operation of these programs is 
discussed in Section 3.4. 

A number of tests of rss remote terminal hardware are scheduled 
on a routine basis. These include a daily diagnosis of the off-line data 
link (discussed further in Section IV), weekly scheduled diagnostics of 
the voice channels between the host and the remote terminal (dis- 
cussed in Section V), and periodical automatic line insulation tests (see 
Section VI). Remote terminal hardware diagnostics are automatically 
run once a day. The off-line microprocessor controller is diagnosed and 
switched on-line daily, and all of the peripheral hardware is diagnosed 
at least once every four days. 

Hardware problems in the remote terminal permanent memory are 
detected by a memory audit that periodically examines every memory 
location. Data parity is checked, and the on-line and off-line data are 
compared. If a fault is detected, the appropriate controller is removed 
from service. 

3.3 Fault recovery and reconfiguration 

If a fault is detected in the active microprocessor controller in the 
rss remote terminal, an attempt is made to automatically recover and, 
if necessary, to switch sides to reach a working hardware configuration. 
The control of this recovery action normally lies with the active 
processor. If it becomes too insane to initiate a switch, the sanity timer 
for the off-line processor will time out and initiate a recovery. 3 

Several levels of initialization are available, ranging in severity from 
a simple restart of the base level program cycle to a complete initiali- 
zation of all data bases and a reset of all peripheral hardware. Repeated 
occurrences of faults will cause an automatic escalation of the initial- 
ization level up to the point where transient telephone calls are cleared. 
A complete initialization (which includes clearing stable calls) can 
normally only be requested manually. 

The different initialization levels and their associated recovery ac- 
tions are: 

1. A Level 1 recovery requests any active background task to abort. 
Program execution is restarted at the beginning of the base level cycle. 
This level is normally the first action taken if a processor or memory 
fault is detected. 

2. In Level 2, a minimal amount of call store is cleared, any active 
background task is aborted, and the processors are switched, if possible. 
An out-of-service processor can be switched on-line unless a switch 
has been inhibited by tty request. 

3. In Level 3, a minimal amount of call store is cleared, and a set of 
emergency audits are run. On their completion, the program cycle is 
restarted. 

4. Initialization Level 4 clears all telephone calls in the transient 
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state and idles their associated peripheral hardware. Any call store 
memory that is not up to date is copied from the off-line side. The 
translation checksum is examined, and if it is not correct, a complete 
translation update from the host is performed. Level 4 is normally the 
highest automatic initialization level allowed. 

5. In Level 5, all call store is cleared, except for a special "never 
cleared" area containing the data link buffers, traffic counts, and post- 
mortem information concerning the ongoing recovery action. The 
periphery is completely idled, and all in-progress telephone calls are 
lost. The translation checksum is examined, and if found to be incor- 
rect, a complete translation update from the host is performed. 

6. All clearing actions of Level 5 are executed in Level 6. The 
translations are unconditionally updated from the host, and the on- 
line/off-line roles of the processors are switched, if possible. This 
initialization level is entered only via a tty request or a manual request 
from the reset button on the rss frame. 

When an rss remote terminal initialization takes place, the main- 
tenance forces at the host and at the sec are notified via an alarmed 
tty output message. This message indicates which microprocessor 
controller was on-line both before and after the initialization, the level 
of initialization, and the program address where the recovery occurred. 
The reason for the recovery action is also given. The reasons include 
various parity check errors, a sanity timer timeout, an attempt to write 
into write-protected memory, a request to execute an invalid program 
instruction, and an attempt to access an invalid peripheral address. 

After a few minutes, when it is clear that further recovery action is 
not going to occur, a "post mortem" message is printed, giving detailed 
information relative to the recovery. Information is printed about both 
the first initialization in the current series, and from the most recent 
initialization. Normally, the initialization process is carried to comple- 
tion by the rss remote terminal programs, and no craft intervention is 
required. If the controller gets in a state where it is continually 
initializing itself, a manually requested Level 6 initialization may 
become necessary. 

When the periodically executed processor sanity tests fail, the re- 
covery mechanism differs from the multilevel initialization process just 
described. The failure of one of these tests normally indicates a 
hardware fault in the on-line microprocessor controller, and the recov- 
ery consists of an attempt to switch to the standby side. If the off-line 
controller is marked out of service, it may or may not be switched on- 
line, depending on the severity of the fault and its potential effect on 
the system. If a processor switch is not completed, the original con- 
troller remains active, with the processor marked faulty. In this state, 
the discovery of new processor faults will not be reported via tty 
output, unless they are severe enough to cause a processor switch. 
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Memory faults discovered by the memory audits also result in a 
processor switch, if possible. A switch will not take place if the off-line 
controller is out of service. 

As with sanity test failures, peripheral faults are also handled outside 
the multilevel initialization procedure, since they normally result from 
peripheral hardware problems. If a fault is detected while attempting 
to execute a peripheral order, one of three problems is assumed to 
exist. The fanout board involved could be faulty, the particular periph- 
eral hardware being accessed could be faulty, or a transient hardware 
failure could have occurred in either the fanout board or the periphery. 

When a peripheral order fails, it is first retried without altering the 
system state. If the retry succeeds, a transient hardware fault is 
assumed and a transient error counter for the on-line side is incre- 
mented. If the number of transient errors exceeds a threshold, the 
system will switch sides, if possible. 

If the peripheral order retry fails, the system attempts to switch 
sides. The peripheral order is then retried from the new controller 
complex. If it succeeds, the original fanout board is assumed faulty. 
The off-line controller is then removed from service, with that partic- 
ular fanout marked bad. If the peripheral order fails on the new side, 
a peripheral hardware failure is indicated. The now off-line microproc- 
essor controller is left in the standby state, and the faulty portion of 
the periphery is marked bad so further access problems with the 
suspected hardware will not result in a processor switch or tty output. 

When two successive peripheral orders fail and a processor controller 
switch is not allowed, it is not possible for the system to differentiate 
between fanout and peripheral hardware faults. In this case, the on- 
line fanout board involved is marked faulty. 

3.4 Error analysis and peripheral circuit disposition 

When a fault is detected in the peripheral hardware, either through 
the mechanism described in the previous section or the various per- 
call tests, the hardware involved is reported to the rss error analysis 
programs located in the remote terminal. The circuits analyzed by 
these programs include network A-links and junctors, Receiver Off- 
Hook (roh) tone circuits, metallic access buses, and Universal Service 
Circuits (uses). Channels and lines receive modified treatment, as 
described in Sections V and VI, respectively. 

The error analysis programs make use of two techniques for analyz- 
ing and pinpointing faulty hardware — peer group analysis and quick 
check. A peer group analysis program compares the error rate of a 
particular member of a group of circuits to the error rate of the entire 
group. The circuits are compared on the basis of a particular error 
type, and any circuitry that shows a high rate of failure relative to the 

SYSTEM MAINTENANCE 607 



other members of the group is reported to the circuit disposition 
programs for possible removal from service. 

The second technique used for peripheral hardware error analysis is 
a success/fail comparison called quick check. The quick check program 
looks for three successive failures from the same circuit. When a 
particular circuit fails three times in a row, an attempt is made to 
automatically remove it from service. 

When a per-call failure is detected by either the peer analysis or 
quick check technique, a tty output message is generated. This 
message details the particular circuit which failed and the failure type. 

The circuit disposition program, located primarily in the host, is 
responsible for acting on requests to remove or restore peripheral 
circuits to and from service. Removal requests can be automatically 
generated by the error analysis programs as just outlined, or they can 
be the result of a manual request from the rss maintenance panel or 
from the host maintenance tty. Restoral to service requests can only 
be made manually. 

When a request is received to remove a circuit from service, it may 
be removed immediately, the request may be denied, or, if the circuit 
is busy, it may be camped on and removed when it becomes idle. A 
removal request can be denied if a predefined out-of-service limit has 
been reached. In this case, a manual request can be made from the 
tty to override this limit and unconditionally remove the circuit from 
service. The camp-on mechanism will not monitor the circuit indefi- 
nitely. After a period of time, the program will time out, and it will be 
necessary to re-request the circuit removal. 

In all cases, the action taken by the circuit disposition programs is 
reported to the craft by host maintenance tty output messages. The 
success or failure of a removal or restoral request is indicated. If a 
removal request failed, the reason for failure is specified. When an 
automatic request from error analysis results in the removal of a circuit 
from service, the error type or types is specified, and the reason for 
removal, either peer analysis or quick check, is given. 

The circuit disposition program also formats and outputs informa- 
tion about the status of rss remote terminal peripheral hardware. Out- 
of-service lists for network A-links and junctors, metallic access buses, 
and uses are output by this program. The current state of any 
individual line can also be determined and printed via the circuit 
disposition program. 

3.5 RSS remote terminal diagnostics and fault repair 

In the rss remote terminal the circuit pack is generally the smallest 
replaceable entity. For this reason, the diagnostics for the remote 
terminal hardware are designed on a per-circuit-pack basis. Each 
diagnostic tests a complete circuit pack, which often contains many 
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individual circuits. For example, the line interface board contains line 
access circuitry for eight lines, the first stage of the switching network 
for these lines, and the metallic interface network between the cus- 
tomer loop and the use which supplies high voltage control, such as 
ringing and coin control. 

The primary requirement for the design of these diagnostics is 
testing completeness rather than fault resolution. Thus, the diagnostics 
are designed to determine which portion of the system (to the circuit 
pack level) contains a fault, not which specific circuit is faulty. In most 
cases, a failing diagnostic pinpoints the faulty board, or at most a few 
suspected faulty boards. 

The tty output message associated with a diagnostic failure will 
usually include enough information to either determine the faulty 
board or suggest further diagnostics that should be run. If a more 
detailed analysis of the failure is necessary, the output message will 
contain raw data that, when used in conjunction with the diagnostic 
program listings, will enable this examination to be done. 

All diagnostics can be requested manually from the maintenance 
tty. The microprocessor controller diagnostics are automatically run 
daily, and all peripheral hardware is routinely diagnosed on a 4-day 
cycle. Except for the channel and data link diagnostics, discussed later 
in this paper, rss remote terminal diagnostics are not run automati- 
cally as the result of a detected failure. Also, a failing diagnostic will 
not remove circuitry from service because of the lack of failure reso- 
lution to the circuit level. 

The rss processor, memory, and fanout diagnostics run on the off- 
line controller only, but diagnostics for the peripheral circuitry will run 
whether the equipment is in service or out-of-service. If a diagnostic is 
run on a circuit pack containing traffic busy circuitry, the tests for that 
portion of the board are skipped. Thus, there are three possible results 
for a peripheral circuit-pack diagnostic. It can pass all tests, it can fail 
some tests, or it can pass every test run, with some tests skipped. Each 
of these cases is detailed with a tty output message, with an indication 
of the number of skipped orders when all tests were not run. 

The diagnostics can be run in one of three modes. In the normal 
mode, the diagnostic is run only to the point where a failure is detected. 
At that point, the diagnostic is terminated and the failure is reported. 
The daily routine diagnostics are run in this mode. An unconditional 
mode exists for cases where the fault resolution of the normal mode is 
inadequate. In this mode, every diagnostic test is run and every failure 
is reported. The third diagnostic mode is the repeat mode. The 
diagnostic, or a portion of the diagnostic, is repeated continually until 
manually aborted. In this mode, the result of the first run through the 
diagnostic, either pass or fail, is reported. On subsequent runs, only 
changes in diagnostic results are reported. This mode is useful when 
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an intermittent failure exists, or when it becomes necessary to use 
external test equipment to monitor the operation of a portion of the 
rss circuitry. 

In addition to using the diagnostics for fault detection, they are also 
useful for fault isolation. In some cases, a diagnostic failure implicates 
only one circuit pack, but in other cases, the failing diagnostic will 
implicate other boards. By diagnosing these circuit packs, the partic- 
ular board that is faulty can usually be identified. In some cases, it 
may be necessary to use the information in the diagnostic program 
listings for a description of the test situation and a detailed analysis, 
using the raw data contained in the diagnostic failure message. 

When a fault has been isolated to one or a few suspected faulty 
boards, a craft person must be dispatched to repair the problem. The 
rss maintenance panel is the normal field interface between the system 
and the craft. Identification numbers of the suspected faulty boards 
must be preloaded in the maintenance panel repair buffer from the 
host maintenance tty. In the field, the craft person can then use the 
panel to sequentially examine each circuit pack. First, the board is 
removed from service and diagnosed. If it fails, it is replaced and 
rediagnosed for repair verification. If it passes, the pack is restored to 
service. If the diagnostic continues to fail, the fault probably lies on 
one of the other suspected faulty packs. In this case, the original board 
can be replaced, and the second suspected circuit pack investigated. 
This procedure is repeated until every circuit pack stored in the 
maintenance panel repair buffer passes its diagnostic. 

IV. PERIPHERAL UNIT CONTROLLER/DATA LINK MAINTENANCE 
4. 1 Peripheral hardware 

A Peripheral Unit Controller (puc) is a microprocessor-based, intel- 
ligent No. 1/1 A ess peripheral. It communicates with the No. 1/1 A 
ess through the peripheral unit bus, the scanner answer bus, a central 
pulse distributor, and a master scanner (see Fig. 3). 

Since the puc is a general-purpose controller used in No. 1/1 A ess 
for such features as Digital Carrier Trunk, and Electronic Tandem 
Switching, as well as the Remote Switching System, puc maintenance 
considerations will not be specifically discussed. The rss requires a 
puc data link (puc/dl); that is, a puc with additional hardware and 
an additional firmware package that allows it to provide an interface 
with up to 16 data links. Because of the dependence of rss on its data 
links, the puc/dl maintenance considerations will be discussed. Other 
aspects of rss data link operation are covered in Refs. 3, 5, and 6. 

Since an rss can serve up to 2000 customers, its communication link 
to the host is duplicated for reliability. The two links are operated in 
an active-standby configuration at a 2400-b/s data rate using the ccitt 
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X.25 link-level protocol. A puc/dl frame can support up to eight rsss. 
Each link connects the host to the Remote Terminal via either Tl or 
N-carrier. If Tl carrier is used, the link consists of the following: 
(i) Line Interface Unit (liu) in the PUC. 
(ii) Special D4 channel bank data port plug-in. 
(til) Standard interface between the liu and the data port. 
(iv) Tl voice channel. 

(v) Data Link Interface (dli) board in the rt. 
If N-carrier is used the link consists of the following: 
(i) Line Interface Unit in the puc. 
(ii) Standard 2400-baud, full-duplex data set. 
{Hi) Standard interface between the liu and the data set. 
(iv) N-carrier voice channel. 
(v) Matching data set at the rt. 
(vi) Data Link Interface board. 

(vii) Standard interface between the modem and the dli. 
It is the task of puc/dl maintenance to detect link-affecting prob- 
lems in any of these components, reconfigure appropriately, and to 
provide diagnostic resolution sufficient to sectionalize the problem. 

4.2 Data link trouble detection and recovery 

Trouble in the data link can be detected by the host 3 or the remote 
terminal 3,6 when a carrier failure, a protocol response failure, or an 
excessive error rate is encountered. When the remote terminal detects 
a problem before the host, it simply stops responding to the received 
data, causing the host to detect a protocol response failure. In any 
case, the host attempts to establish a working configuration using the 
standby link. The faulty link is then diagnosed and reported to the 
craft person by a host tty message. If both links to the rss are faulty, 
the remote terminal will go into a stand-alone mode. Host recovery 
programs continue to periodically diagnose the links and will auto- 
matically bring the data links back on-line when the trouble clears. 

Faults requiring manual intervention require additional software 
tools. The tty messages are provided to request the data link status, 
restore a data link to service, remove an active link from service, and 
diagnose a data link. In rare cases, tty messages can be used to force 
a link active or detain a link out-of-service; thus, overriding the system 
checks and forcing the system to use or not use a specified link. 

4.3 Data link diagnostic 

A data link diagnostic can be requested manually or automatically. 
It is composed of seven phases which test the various sections of the 
data link by looping signals at different interfaces, applying enough 
load to stress the system, and observing the results (see Fig. 4). The 
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Fig. 4 — Data link loop tests. 
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diagnostic can print in the normal or raw data modes. It can run all 
phases, begin and end at a specific phase, or loop on a particular phase. 
Phase 1 tests host access to the Liu. Phase 2 loops the host signal at 
the liu. Phase 3 loops the host signal at the host modem or data port. 
Phases 4 and 5 consist of tests run at the rt. Phase 4 verifies proper 
operation of the dli board and performs a local loopback from the 
remote terminal controller to the dli. Phase 5 remotely loops the 
signal at the remote terminal Tl interface or modem, depending on 
the facility. Phase 6 is a hardware end-to-end loop consisting of 1000 
frames of data; fewer than 10 errors is considered as an All-Tests- Pass 
(atp), fewer than 100 errors is characterized as a degraded link, and 
more than 100 errors is considered a failure. Phase 7 attempts end-to- 
end communication by sending a message to the remote terminal 
controller, and waiting for a response. This phase fails if a response is 
not obtained within a reasonable period of time. 

V. REMOTE SWITCHING SYSTEM CHANNEL MAINTENANCE 

5. 1 Channel maintenance overview 

A channel is a Special Service Circuit, similar to a voice trunk, 
connecting the rt to a line appearance on the host No. 1/1 A ess. A 
channel looks like a line to call processing programs, enabling most 
No. 1/1 A ess line features to be readily available to any rss customer 
when connected to a channel. In the areas of maintenance and traffic 
usage, however, channels more closely resemble trunks. With a traffic 
usage of up to 25 ccs/channel, a faulty channel can potentially affect 
many customers; therefore, weekly diagnostics, per-call-failure tests, 
error analysis, and manual access arrangements are required to main- 
tain them adequately. 

At least a part of every normal rss call involves a link from the rss 
to the ess consisting of an rss line circuit, an rss network connection, 
and an rss channel. Since this link did not exist when the Direct 
Distance Dialing (ddd) transmission allocation plan was developed, it 
was not given any loss allocation. This link must then have a nominal 
0-db loss characteristic. This requirement led to the transmission plan 
detailed in Ref. 2. This plan requires tight control of the channel 
transmission characteristics. Automated monitoring of rss channel 
transmission performance is provided by the Centralized Automatic 
Reporting On Trunks (carot) system. 

Since the rss is simply a remote extension of the host ess, the 
maintenance of both ends of the channel becomes the natural respon- 
sibility of the host. This allows the automatic testing of channels to be 
superior to that provided for most trunks. 
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Fig. 5 — Remote switching system channel maintenance terminology. 



5.2 Design approach 

Because of the similarity between channels and trunks, the possibil- 
ity of using the existing No. 1/1 A ess trunk maintenance programs 
was appealing. Connecting the host line appearance of an rss channel 
to one port of a loop-around trunk allows the unconnected port (and, 
therefore, the channel) to be treated like a trunk (see Fig. 5). Two 
criteria were considered vital in the implementation of the design. The 
first: minimize the differences between rss channel maintenance and 
No. 1/1A ess trunk maintenance so that it is unnecessary for the craft 
person to learn new and radically different procedures. The second: 
minimize software changes by making the rss channel look as much 
like a trunk as possible. 

5.3 Channel maintenance functions 

Channel maintenance functions can be divided into two major 
categories: automatically initiated testing and manually initiated test- 
ing. 

5.3. 1 Automatic maintenance functions 

The following six automatic maintenance functions are provided for 
channels: 

(i) Per-call failure processing 
(ii) Audit failure processing 
(Hi) Automatic progression testing 
(iv) Error analysis 
(v) Transmission testing 
(vi) Software state control. 
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Per-call failure processing refers to the action taken by the channel 
maintenance programs when call processing suspects a channel fault. 
Even though a faulty channel can potentially affect many customers, 
real-time considerations prevent all channels from being fully diag- 
nosed more than once a week. It, therefore, becomes the responsibility 
of call processing to inform maintenance when a faulty channel is 
suspected. Examples of per-call tests include testing if off-hook super- 
vision can be successfully transferred over a channel from an rss line, 
and a host network continuity test from the channel to a trunk circuit. 
When such tests fail, call processing programs attempt to place the 
channel on the Channel Maintenance List (cml). The cml is a queue 
of channels that are awaiting a system diagnostic. If the diagnostic 
fails, the channel is retested after a 5-second delay. If the channel fails 
both diagnostics, it is removed from service (i.e., locked out) as long as 
the Automatic Maintenance Limit (aml) has not been exceeded. In 
any case, two messages are printed on all failures to inform the craft 
person of both the failure and the disposition of the channel. If either 
test passes, rt error analysis is informed and the channel is returned 
to the traffic-idle, maintenance in-service state. 

Audit failure processing takes place when system audits find a 
channel in an invalid state. The channel is placed on the Channel 
Maintenance List for Audits (cmla). The cmla is a queue of channels 
that are awaiting a blind-idle of their hardware. After the channel is 
hardware idled, the control program attempts to place the channel on 
the cml. 

Automatic progression testing is the primary vehicle used to allow 
channel maintenance to detect and remove faulty channels before they 
are used by call processing, and cause calls to be lost. Beginning at 
1:00 a.m. every Monday morning, channel automatic progression test- 
ing begins at the first idle channel in the first- assigned rss. The 
diagnostic, software state control, and printing are exactly as described 
for the cml. When all channels in the rss have been tested, testing 
continues with the first idle channel in the next rss. Testing continues 
until all idle channels in all assigned rsss are tested, or until 6:00 a.m. 
If testing has not been completed at that point, it is resumed each 
morning thereafter between 1:00 a.m. and 6:00 a.m. until all idle 
channels have been tested. 

Error analysis for channels is carried out in much the same manner 
as described in Section 3.4 for the rt. All channel error analysis counts 
are kept in the rt. A data link message is sent to the rt every time a 
channel passes a cml diagnostic sequence in the host. In addition, the 
rt records every time a channel is involved in a half-path continuity, 
a half-path cross, or a ci board failure. If an individual channel fails in 
three consecutive usages (quick check failure) or performs poorly in 
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relation to other channels (peer analysis failure), a data link message 
is sent to the host resulting in the channel being removed from service 
if the aml is not exceeded. 

Automatic routine transmission testing is provided using a carot 
system. Software modifications were necessary to allow: 

(z) A line equipment number to be substituted for a trunk network 
number as the circuit identifier for carot testing. 

(ii) A channel modifier digit specifying the state of the balance 
network and 2-dB pad instead of a trunk modifier digit specifying the 
trunk state. 

The carot system interfaces with a Remote Office Test Line (rotl) 
in the host machine and a miniresponder 4 in the rt. (The rt minire- 
sponder is a miniaturized single-board version of the 52 A responder 
used in the rotl.) All appropriate carot capabilities that are available 
on No. 1/1A ess trunks have been provided for rss channels. The 
Processor Controlled Interrogator (pci) allows the use of the rotl 
equipment from the local office or an sec without the aid of carot. 
The pci is used primarily to verify that problems reported by carot 
have been corrected. 

Software state control refers to the automatic administration of rss 
channel maintenance states. Although one of these states is usually 
related to a hardware state, it is strictly a software construct. This 
software state, which may be permanent or transitory, is encoded in 
per-channel memory. The following maintenance states have been 
provided for rss channels: 

(z) ACTIVE — Available for use by both call processing and main- 
tenance. 

Hi) HIGH AND WET— Host side of the channel is off-hook and 
not involved in a connection. A channel in the high and wet state is 
unavailable to call processing. Channels are automatically removed 
from this state when they go on-hook. The most likely reason for the 
channel being in the high and wet state is a carrier failure. 

(Hi) CHANNEL MAINTENANCE LIST— Queued for a deferred 
channel diagnostic and temporarily unavailable to call processing. 

(iv) LOCKED OUT — Out-of-service and permanently unavailable 
to call processing without manual intervention. Channels can be locked 
out by error analysis, automatic progression, or cml processing and 
manual requests from the tty or one of the trunk test panels. 

(v) CHANNEL MAINTENANCE LIST FOR AUDITS— Queue 
of channels found in an invalid state by the system audits and waiting 
to be blind-idled. Temporarily unavailable to call processing. 

5.3.2 Manual channel maintenance functions 

Manual channel maintenance functions can be requested from the 
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ess maintenance ttys, as well as from the ess trunk test panels. 
Remote control from the sec is also possible. 

Single-channel diagnostics can be executed in one of two modes: 
normal and raw. A normal mode diagnostic indicates the general area 
of the fault. A raw diagnostic printout, with the help of the rss channel 
trouble location manual, can be used to localize specific channel faults. 

A single-channel transmission test can be requested using the rt 
miniresponder as a 102-type Far-End Test Line (fetl) for a 1-way 
(rss to ess) loss measurement, a 100-type fetl for a 1-way (rss to 
ess) loss and noise measurement, or a 105-type fetl for 2-way loss, 
noise, noise with tone, and gainslope measurements. During any of 
these tests, the switchable transmission components at the remote 
terminal end of the channel (described in Ref. 7) can be placed in most 
of their allowed states. 

In addition to the single-channel maintenance functions, three types 
of multiple channel test requests are provided: group tests, repeat 
tests, and diagnosis of all out-of-service channels. These functions are 
provided to increase the efficiency of a craft person in localizing a 
transient fault or a single fault which affects multiple channels. Group 
tests allow the craft person to request a diagnostic or transmission test 
on all channels associated with the specified rss. A repeat test allows 
the craft person to diagnose a channel 32 times in a row and print only 
the failures. A diagnosis of all out-of-service channels allows the craft 
person to quickly verify that these channels are still faulty. 

In addition to the automatic software state control discussed earlier, 
channels can be manually locked out or made active. Manual state 
changes are not subject to the aml. If manual actions cause this limit 
to be exceeded, the craft person will be so informed. 

Access to channels from manual test positions is provided to permit 
initial channel alignment and testing, and manual testing when system 
diagnostics provide insufficient trouble localization. The following 
functions are provided: 

(i) DC access from the panel to the channel facility. 
(ii) DC voltage measurements. 

(Hi) Connection from the panel to the channel to a 102-type fetl. 
(iv) Monitoring or measuring of ac tones. 

(v) Connection from the panel to the channel to a 100-type fetl. 
(iv) Noise measurements. 

(uii) The ability to send an ac tone from the panel and detect it at 
the rt. 

(viii) The ability to control the 2-dB pad, the state of the hybrid 
balance network, and the off-hook/on-hook state of a channel con- 
nected to the panel. 

The following channel list functions are provided: 
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(i) A list of all out-of-service channels. 
(ii) A list of all high and wet channels. 
(ill) A list of all idle channels in a specified rss. 
(iv) A list of all rsss with the number of out-of-service channels 
exceeding the aml. 

(v) A list of all channels in a specified rss and their overriding 
maintenance state. 

The ability to request the traffic and maintenance state of a single 
channel is also provided. 

5.4 Channel diagnostic tests description 

The approach taken by the channel diagnostic is to emulate all 
operations performed on a channel during a call, verifying in each 
instance that the channel performs satisfactorily. The hardware com- 
ponents that make up an rss channel are described in Ref. 4. 
The following nine channel tests are performed: 

(i) Power Cross — A check to detect commercial power crosses at 
a channel's host line appearance. 

(ii) False Cross and Ground — A check for path crosses or grounds 
in the portion of the ess network involving a channel. 

(Hi) Supervision — A check that the on-hook and off-hook state of 
a channel can be passed from the rt to the host. 

(iv) Restore Verify — A check that the line ferrod can be connected 
and disconnected via the line cut-off relay on the host line link network. 
(v) Low Line Resistance — A check of the resistance across tip and 
ring at the host to detect a condition where this resistance is so low 
that an on-hook channel would erroneously trip ringing and cause false 
billing. 

(vi) Showering Line — A check of the resistance across tip and ring 
at the host to detect a condition where the on-hook and off- hook status 
of a channel varies depending on whether the channel is supervised at 
the line ferrod or at a service circuit. 

(vii) Dial Pulse — A check of the ability of a channel to successfully 
transmit a dial pulse zero (10 pulses) to a host dial pulse receiver. 

(viii) AC Far-To-Near — A check of the ability of a channel to 
successfully transmit an ac tone from the rt to the host. 

(ix) AC Near-To-Far — A check of the ability of a channel to 
successfully transmit an ac tone from the host to the rt. 

It may be noted that this diagnostic does not provide any test of 
that portion of the rt network physically located on the ci board. This 
network testing function is performed by the Rss-controlled ci board 
diagnostic. This has the disadvantage that complete testing of a newly 
replaced ci board requires that one ci board and four individual 
channel diagnostics be requested. The overriding advantage of this 
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approach is that it permits a host controlled end-to-end functional test 
of the channel without creating an unacceptable resource contention 
problem with the rss. 

VI. REMOTE SWITCHING SYSTEM LINE MAINTENANCE 

6. 1 Line maintenance overview 

The overall approach to rss line maintenance is to extend from the 
host ess all existing line maintenance features and to implement within 
the rt any maintenance feature uniquely required for rss lines. Stand- 
ard line maintenance features are normally divided, both functionally 
and administratively, into two types: 

(i) Testing of the metallic customer loop and associated station set. 

(ii) Testing of the central office per-line circuitry. 

While rss requires no changes to a properly designed outside plant, 2 
the rss per-line circuitry 4 is considerably more complex than the per- 
line circuitry in the ess. 8 Both systems have line circuits that provide 
the basic functions of switching network protection, line attending, 
and voice network access. However, the rss's nonmetallic voice-switch- 
ing network requires that its line circuits provide dial pulse reconstruc- 
tion, talking battery, and test access, all of which are provided by 
service circuits in the host ess. The rss line circuit must also provide 
metallic access to its shared service circuits for such functions as 
ringing and coin control. In addition, space and power considerations 
require a constant current loop-feed design, which in turn requires 
special line circuit provisions for anticorrosion biasing, detection of 
ground start originations, and switchable line feed states. 

Therefore, traditional outside plant functions like Automatic Line 
Insulation Tests (alit) and Local Test Desk (ltd) have been imple- 
mented by providing new rt hardware 4 with the necessary dc access, 
and generalizing the host programs to control the new hardware via 
the data link, whereas new per-line circuit functions, such as diagnos- 
tics and error analysis, have been implemented in the rt. 

6.2 Line maintenance functions 

The maintenance functions provided for rss loops include: 
(i) Per-call loop tests, performed automatically by the system. 
(ii) Automatic line insulation tests, normally performed on a rou- 
tine, scheduled basis. 

(Hi) Manual testing from the local test desk, normally performed 
only when trouble is suspected. 

(iv) Station ringer and TOUCH-TONE* dialing tests, normally 
initiated from the customer premises when a station set is installed. 



* Registered service mark of AT&T. 
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Maintenance functions provided for rss line circuits include: 
(i) Per-call tests of various line circuit functions. 

(ii) Routine exercises, which provide, on a scheduled basis, a com- 
plete diagnosis of the line circuit. 

Each of these functions is described in more detail in the following 
paragraphs. 

6.2.1 Loop maintenance functions 

The number of per-call loop tests that can be made are restricted by 
considerations of call setup time and processor capacity. As a result, 
these tests are limited to those which establish that the line can safely 
be placed in a connection, and that the subsequent call disposition can 
be monitored. These tests are as follows: 

(i) Power Cross Test — Before a metallic connection is set up to 
apply ringing, a test is made for voltages on the loop which may 
damage the ringing circuit. 

(ii) Ringing Continuity Test — Shortly after ringing voltage is ap- 
plied to a line, a current measurement is made to establish that a 
ringer is actually connected to the loop. 

(Hi) Showering Line Test — The rss line circuit is more sensitive to 
dc loop current in the idle state than in the talking state. This can 
cause some leaky lines to "shower" (that is, continually appear to 
originate and then immediately hang up when put in a dialing connec- 
tion). To prevent this, the line is scanned with the line circuit in both 
the idle and the talking states when an origination is detected. 

When any of these three tests fail, an immediate report is made on 
a host tty, identifying the line and the nature of the failure. This 
immediate reporting, which differs from the usual rss error-analysis 
approach, is necessitated by the immediate customer service impact of 
these failures. Also, in the showering line case, the system must take 
defensive action (placing the line high and wet) to avoid being flooded 
with origination reports. 

Permanent Signal and Partial Dial (pspd) timing is another per-call 
loop "test," but one requiring much different treatment. Although 
faulty customer loops sometimes evidence themselves this way, pspd 
failures are more often induced by customer actions. A pspd timeout 
occurs when a line originates but does not dial at all (permanent 
signal) or does not dial successive digits (partial dial) within 20 seconds. 
As a result, the line is connected successively to an appropriate 
recorded announcement, receiver-off-hook tone, and finally an opera- 
tor. If none of these actions results in the line going on-hook, the line 
is placed high and wet. After an additional timing interval specified by 
the Bell operating company, the line is reported on a host tty. A 
summary list of all high and wet lines (both host ess and rss) is 
available by manual tty request. 
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The Automatic Line Insulation Test (alit) provides automatic, 
routine surveillance of customer loops for insulation breaks in wire, 
cable sheath, and cable terminals. The rss lines are tested under the 
control of the host ess, using measuring circuitry in the rt. On a 
schedule established by the Bell operating company, the host alit 
control program sequences through all testable host and rss lines in 
order of telephone number. For each rss line, a data link message is 
sent, identifying the line and requesting an alit test. The rt performs 
the test, returning the results to the host. Failing results are reported 
on the appropriate host tty. 

There is one respect in which alit failures on rss lines require 
special interpretation and screening. The anticorrosion biasing ar- 
rangement may be ineffective on lines with localized, very low resist- 
ance leakage paths to ground. The alit failure reports in this category 
provide the only automatic indication of an rss line subject to corro- 
sion. 

In addition to performing routine testing, the alit circuit in the rss 
may be used in the "demand" mode, via host tty request. These tests 
may select different test types or ranges from those used for routine 
testing. Either a single line or all testable idle lines in a particular rss 
may be tested via a single tty request. 

The rss lines are accessible for testing from standard Local Test 
Desk (ltd) No. 14, or No. 16. Access arrangements depend on the 
distance from the test desk, through the host ess, to the rss. When 
this distance is within metallic testing range, a metallic access arrange- 
ment is provided. In this case, mechanized loop testing (mlt) access is 
also supported. Otherwise, access is via a modified version of the ltd 
Remote Test System (ltdrts). From a user's point of view, both 
arrangements duplicate the majority of existing ltd functions. Certain 
functions (e.g., operation of the no test vertical key) do not apply 
because the rss testing configuration is different. Other functions, like 
verifying that a ground start line can originate, cannot be performed 
because of design limitations. (The required ground start applique is 
automatically placed in the bypass state and the line is "tested" as a 
loop-start line.) When an ltdrts is required, additional differences 
occur. To use a standard system at the ltd, nonstandard arrangements 
are provided in the host and the rt. The host must be able to detect 
a limited set of control oriented test requests (e.g., origination, discon- 
nect, line ferrod), while test configuration requests are detected and 
acted upon at the remote terminal. This new hardware requires the 
ltd to use a different test trunk or test trunk group to obtain access to 
rss lines than that used to access host ess lines. It also requires a 
connection to an rss line before rts test battery voltages can be 
checked. (Existing systems require only a connection to the cdo.) A 
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complete description of the rss line test hardware is included in 
Ref. 4. 

All customer trouble reports are received at the Repair Service 
Bureau (rsb) which has primary responsibility for maintaining satis- 
factory service to customers. The rsb performs tests to determine if 
the trouble is internal or external to the RSS. Since the rss line circuitry 
is more complex than the per-line circuitry of most existing switching 
systems, and because the rss line circuit cannot readily be isolated 
from the customer loop, the internal-external decision is more compli- 
cated for rss lines. In some cases, rss line and ground start applique 
diagnostics will be needed to help localize the problem. Therefore, rss 
line testing requires more coordination between the rsb and the sec. 

When a telephone set is installed, or repaired, the Station Ringer 
and TOUCH-TONE dialing test equipment can be accessed via a 
telephone company assigned directory number to perform any of the 
following tests: 

(i) TOUCH-TONE Dialing Test— A verification that a predeter- 
mined digit sequence can be correctly dialed from a 10- or 12-button 
telephone set. 

(ii) Automatic TOUCH-TONE Dialing Test— A verification that a 
predetermined digit sequence is dialed at the correct rate from a 12- 
button automatic dialer set. 

(Hi) Party Ground Identification Test — An off-hook resistance mea- 
surement from simplex tip and ring-to-ground. 

(iv) Leakage Test — An on-hook resistance measurement from sim- 
plex tip and ring-to-ground. 

(v) Ringing Test — A test of the ability to ring the customer phone. 

For Station Ringer and TOUCH-TONE dialing testing of rss lines, 
no special circuits are required at the rt. An rss line accesses the host 
ess Station Ringer and TOUCH-TONE dialing test circuit via a 
channel, and the host circuit is used for the TOUCH-TONE dialing 
tests and for all tone signaling to the line. Party ground identification 
and leakage tests are performed by the rss upon host data link request. 
The results are returned to the host which, in turn, conditions the 
Station Ringer and TOUCH-TONE dialing test circuit to signal the 
appropriate test result tone. The ringing test is performed by the rss 
in a similar manner. 

6.2.2 Line circuit maintenance functions 

Generally, each time the rss firmware accesses a line circuit to 
perform a function, a test is made to ensure that the action is successful. 
This approach is supported by comprehensive test access and by the 
fact that the tests can be made quickly (i.e., with an acceptable penalty 
to call setup time and processor capacity). Among the per-call tests 
performed on a line circuit are the ability of the circuit to 
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(i) Place the loop feed in the talking (high power) state. 
(ii) Provide a path for network holding current. 

{Hi) Operate and release relays which provide access to the metallic 
network. 

(iv) Place the loop feed in the idle (low power) state. 
(v) Open the path for network holding current. 

Failure of any of these tests is reported on the host maintenance 
tty and also analyzed by standard rss error analysis. If the failures 
exceed the error analysis threshold a high priority trouble message is 
printed on the host tty. Some of these failures are subject to additional 
processing by the rss firmware. For example, loss of power to a line 
circuit causes the line to appear to originate. Therefore, when the 
attempt to place a line in the talking state fails after an origination is 
detected, further tests are made and, if appropriate, the failure is 
reported at the host ess specifically as a "no power" condition. 

All assigned rss line circuits are diagnosed as part of the rss routine 
exercise program. Both the scheduling control and the diagnostic logic 
reside entirely within the remote terminal. In addition, any single rss 
diagnostic may be requested via a tty at the host ess. When manually 
requested, the diagnostic may be performed in any of the three modes 
described in Section 3.5. 

The remote terminal diagnostics are partitioned to permit complete 
testing of a single plug-in circuit board with a single request. For most 
customer lines, this partitioning allows all diagnosable circuitry asso- 
ciated with a single line to be tested via a single request for a line 
interface board diagnosis. Certain lines, however, such as ground start, 
and coin lines, require an additional request to diagnose the associated 
ground start applique. 

VII. SUMMARY 

The rss maintenance plan has been made as consistent as possible 
with existing Bell operating company switching system procedures, 
but the geographical separation of the various system components has 
required modifications and additions to these procedures. In addition 
to the switching craft charged with rss maintenance responsibility, 
several other craft forces (e.g., outside plant, data services, ltd, carrier, 
trunk maintenance, etc.) will become involved in the maintenance of 
various portions of the rss. The required coordination of these differ- 
ent craft forces will make new Bell operating company maintenance 
procedures necessary. 

The maintenance of each major portion of the rss has been discussed 
in detail. Remote terminal maintenance activities are carried out 
nearly autonomously, with little interaction required between the host 
ESS and the RT. Both hardware and software checks are utilized to 
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detect system faults, and automatic recovery, circuit removal, and 
fault reporting are utilized when a fault is detected. Manual diagnostics 
are available for detailed fault location and repair. 

The puc/dl is a direct peripheral unit of the host ess. Its mainte- 
nance is coordinated closely with that of the host. 

The rss channel maintenance has been made to look as much like 
ess trunk maintenance as possible. Per-call-failure tests, error analysis, 
and manual maintenance access arrangements, similar to those existing 
for trunks, have been provided. 

Numerous existing line maintenance features (e.g., alit, ltd access, 
etc.) have been extended to rss customer loops from the host ess. In 
addition, the increased complexity of the rss per-line circuitry has 
made new maintenance functions necessary. 
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